如何合併Sitecore Server Roles

前言

經手過Sitecore的人應該都非常熟悉Sitecore的幾大架構，像是XP0、XP1，這種Sitecore定義出來的網路拓樸，但看著官方文件上掛著Server Role之間是可以合併的，並且直到10.3版本的Document上，甚至還寫出了常見的合併方式，最近終於在文件上看到如何合併的字樣了。
禁不住的好奇，加上前一陣子才準備好一整套SIF的安裝腳本，對於安裝Sitecore又更熟了一點，就來研究一下如何合併Sitecore的Server Role吧!

環境

撰寫當下，Sitecore版本為10.3.1，正在如火如荼地推動好像很厲害的XM Cloud，測試使用的OS為Windows Server 2022。

構想

既然都是自建的拓樸了，不免俗的要來規劃一下。

執行安裝

嘗試安裝

Q:是不是一直重複裝在同一個位置就好了呢?
Ans:不，因為部分json設定的Task會將原有資料清除或者已有資料回應錯誤，因此這樣做部分不可行。

Q:是不是和裝hotfix之類的一樣，將SIF的update參數設定為true就好了呢?
Ans:不，他只會覆蓋和安裝檔案中不一樣的內容，在安裝Content Management與Processing的時候就會發現這一點，web.config將會被蓋過去，且仔細看過json設定檔案，該設定會導致部分Task不執行，所以不是這樣做的。

安裝cm.demo.com

Content Management

沒有什麼特別的...依照往常Sitecore原廠安裝方式執行即可。

xDB Processing

在分開安裝Content Management、xDB Processing後，取出整個站台內容對照，發現整個站台竟然只有web.config設定有差異(還有個keepAlive排程，Processing竟然連domain都打上去了，Content Management平常很常因為缺少domain導致回收AppPool後，網址變成localhost產生錯誤...)，因此應該是調整web.config中appSettings/role:define的設定值為ContentManagement, Indexing, Processing，也就是直接新增一組Role給CM使用，連安裝的動作都可以省下來，相同類似的作法可以在Sitecore說明如何設定EXM Dispatch的文章中看到，但還要再加上Processing使用的連線字串。

1. xdb.processing.pools
2. xdb.referencedata
3. xdb.processing.tasks

安裝xconnect.demo.com

xConnect Collection

沒有什麼特別的...依照往常Sitecore原廠安裝方式執行即可。

Sitecore原廠所提供的合併方式，安裝後再調整相關的設定啟用
Manually enable the xConnect Collection service

xConnect Collection Search

xConnect Collection Search主要不同的點在於有一個Windows服務「IndexWorker」，但是其它站台檔案大致上都與xConnect Collection相同(包含Bin資料夾與web.config內容)，因此就是採取直接在同一路徑上安裝的作法即可。

Manually enable the xConnect Collection Search service

安裝marketing.demo.com

Marketing Automation Reporting

沒有什麼特別的...依照往常Sitecore原廠安裝方式執行即可。

Manually enable the Marketing Automation Reporting service

Marketing Automation Operations

Marketing Automation Operations主要是有一組Windows服務「AutomationEngine」，基本上先裝完Marketing Automation Reporting，再來裝Marketing Automation Operations就沒什麼問題，策略和xConnect Collection Search的安裝方式一樣是直接在同一路徑上安裝。

Manually enable the Marketing Automation Operations service

安裝cortex.demo.com

Cortex Processing

沒有什麼特別的...依照往常Sitecore原廠安裝方式執行即可，但在這一部份Sitecore指出僅有部分支援，因為Windows服務並不會合併到網站之中(但安裝包裡面是一個網站和一個服務合併，所以就是作為一個獨立的網站來安裝)。

Cortex Reporting

由於連線字串有差異，就沒辦法像先前幾個Server Role無腦直接在同一路徑上安裝就結束了，安裝完畢後，開啟cortex.demo.com\App_Config\ConnectionStrings.config，補上Cortex Processing所需要的連線字串。

1. processing.engine.storage
2. processing.engine.tasks

安裝中碰到的問題

過程中一些沒有要做合併動作的Server Role都給跳過了，但實際上還是有裝起來確認都是正常的，基本上透過Sitecore提供檢視健康狀態的頁面都是正常的，唯獨Cortex的是有問題的，瀏覽器一開始無法進入，但檢查IIS卻又都是正常回應200的，後來又想到之前曾經碰到Sitecore在部分情況開啟TLS1.3是不正常的，所以就去IIS設定中，把TLS1.3停用之後，就可透過瀏覽器正常取得檢查結果了。只能說Windows更新換代之後，預設啟用TLS1.3的動作可能又要掀起一陣哀號了...。

伺服器健檢

既然Sitecore在目前版本都提供健康檢查頁面了，當然就好好地給他用下去，二話不多說，上Code。

因為只有做一台Lab，所以所有角色都在同一台伺服器中，
透過跟著IIS一起安裝進來的PowerShell模組取得https的網站，再來就是每個組出一組健康檢查頁面的網址去打一下就結束了

Import-Module WebAdministration  
Get-ChildItem IIS:\Sites | ForEach-Object {  
    $siteName = $_.Name;  
    $_.Bindings | ForEach-Object {  
        if ($_.Collection.protocol -eq "https") {  
            $arr = $_.Collection.bindingInformation -split ':'  
            $urlBuilder = New-Object System.UriBuilder @($_.Collection.protocol, $arr[2], $arr[1], "healthz/ready");  
            Write-Host "Invoke Request to "$($urlBuilder)" start..." -ForegroundColor Green;  
            $resp = Invoke-WebRequest $urlBuilder.ToString();  
            Write-Host "$($siteName) Result: $($resp.Content)";  
            Write-Host "Invoke Request to "$($urlBuilder)" end..." -ForegroundColor Green;  
        }  
    }  
}  

最後稍微看個幾眼Content Delivery的範例頁面，移動一下滑鼠，觸發一次收集Page View的事件，再回到Content Management看個報表，確定資料能正常寫入，收工!

結語

原本是想連EXM Dispatch都一起裝看看的，但發現這個安裝包的大小怎麼和CM差不多，越翻怎麼越來越多文件要看?最後還是果斷放棄，畢竟在Sitecore所提供的安裝Guide中是沒有這一組說明的。
大致上最早思考的是裝在同一個位置的思路是很直覺且正確的，但需要注意一下各種安裝檔案內容的差異，執行的動作大概都是把要合併的東西都裝在同一個位置，然後調整連線字串成所有被合併Server Role所需要的連線內容就好了，可能會想說:「真的沒有其他差異嗎?」，因為各個角色Role不使用的檔案會被加上附檔名disabled，要使用的則是正常xml或者config，因此在WebDeply動作不是執行全部刪除後發佈的情況下，啟用和未啟用的檔案會被分開，從檔案系統上看，合併的內容是啟用，也就是兩個Server Role都是啟用狀態，那最尷尬的:「Web.config和ConnectionStrings.config呢?」，大部分依照Sitecore官方文件提示的方式合併，Web.config的內容都是一樣的，所以才會很多動作都是去調整連線字串給各種Server Role來使用

雖然實際上的情境，手上會有的Server數量大概都還是和XP0差不多，不如直接拿XP0的安裝包來用。但訂閱制當道的現在，計算授權也不再這麼斤斤計較，應該更能夠依照現有的資源組合出合適的拓樸出來。

參考

1. Scaling and configuring Core roles
2. Scaling and configuring XP service roles
3. Monitoring the health of web roles